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Abstract 
This document describes the plan to transition responsibility for 
bridging-related MIB modules from the IETF Bridge MIB Working Group 


to the IEEE 802.1 Working Group, which develops the bridging 
technology the MIB modules are designed to manage. 
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Appendix B. Sample Text for IEEE to Request Rights from Authors 
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1. Introduction 


This document describes the plan to transition responsibility for 


2006 


bridging-related MIB modules from the IETF Bridge MIB WG to the IEEE 


802.1 WG, which develops the bridging technology the MIB modules 
designed to manage. The current Bridge MIB WG documents are 


o “Definitions of Managed Objects for Bridges" [RFC4188], 


are 


o "Definitions of Managed Objects for Bridges with Rapid Spanning 


Tree Protocol" [RFC4318] 


o “Definitions of Managed Objects for Bridges with Traffic Classes, 


o “Definitions of Managed Objects for Source Routing Bridges" 
[RFC1525]. 


Multicast Filtering, and Virtual LAN Extensions" [RFC4363], and 
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al. 


2. 


2. 


This document is meant to establish some clear expectations between 
IETF and IEEE about the transition of Bridge MIB WG MIB modules to 
the IEEE 802.1 WG, so that the plan can be reviewed by the IESG, IAB, 
IETF, and IEEE. Some case-by-case situations might arise, which will 
be handled by the appropriate liaisons, but this document describes 
the general strategy. 


1. Motivation 


Having SNMP MIB modules to provide management functionality for its 
technologies is important for the 802.1 community, so it needs to 
charter this work as part of the Project Authorization Requests 
(PARs) for each new project, to ensure that resources are being 
mobilized for execution. This is also true with respect to MIB 
support for already completed 802.1 projects - maintenance projects 
need to include the development of SNMP MIB modules. 


The IESG has mandated that IETF WGs that produce a protocol are also 
required to develop the corresponding MIB module rather than leave 
that to "the SNMP experts" to do later. Part of the motivation was 
obviously to make the protocols more manageable, but part of the 
motivation was also balancing the workload better and getting the 
content experts more involved in the management design. If such work 
comes into the IETF from other standards development organizations 
(SDOs), then we encourage the other SDO to bring in subject matter 
expertise to work with us, or, even better, to take the lead 
themselves. 


The manpower problem is certainly an aspect that is relevant. IEEE 
802 MIB documents could be developed in the IETF, but only if the 
subject matter experts come to IETF to participate in (lead) the 
work. The content experts need to be more involved in the MIB module 
development, and resources need to be dedicated to completing the 
work, whether editing is done in the IEEE or the IETF. The IETF 
finds it acceptable if other organizations (like IEEE 802) do MIB 
documents themselves, and the IETF offers to help review them from an 
SNMP/MIB/Structure of Management Information (SMI) perspective. This 
is true even after the transition, since quality MIB modules are 
important for smooth management of the Internet and the technologies 
it runs on. 


New IEEE MIB Work 
1. New MIB PARs 
The IEEE-SA Standards Board New Standards Committee (NesCom) deals 


with the Projects Approval Requests; see 
http://standards.ieee.org/board/nes/. PARs are roughly the 
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equivalent of IETF Working Group Charters and include information 
concerning the scope, purpose, and justification for standardization 
projects. 


Following early discussions concerning the transfer of MIB work from 
the IETF Bridge MIB WG to the IEEE 802.1 WG, the development of SMIv2 
MIB modules associated with IEEE 802.1 projects has been included 
within the scope of the work of new projects. 


The latest Project Approval Requests (PAR) of the 802.1 projects, 
starting with the P802.lah (Provider Backbone Bridges) approved in 
December 2004, include explicit text on this respect. 


For example, the PAR form of the IEEE 802.1lah, Provider Backbone 
Bridges [PAR-IEEE802.lah], includes in Section 13, "Scope of Proposed 
Project", an explicit reference to ’support management including 
SNMP’. 


Although it is not mandatory that the MIB development work be 
specified explicitly in a new PAR to have the work done (see work 
done in IEEE 802.1AB [IEEE802.1AB] and IEEE 802.1AE [IEEE802.1AE]), 
it is recommended that IEEE 802.1 WG PARs include explicit wording in 
the scope section wherever there is a need for MIB development as 
part of the standard. 


Since the IETF Bridge MIB WG does not intend to develop MIB modules 
in the future, submitters of new work in the bridge management space 
should be directed to the IEEE 802.1 WG, and it should be recommended 
that they not publish their proposed MIB modules as Internet-Drafts. 


2.2. IEEE MIB Modules in ASCII Format 


Making MIB modules freely and openly available in an ASCII format 
will be a critical factor in having the SNMP community accept the 
transfer of 802.1 MIB development from IETF Bridge MIB WG to IEEE 
802.1 WG. Although 802.1 can certainly decide to publish MIB modules 
only in the PDF format that they use for their documents, without 
publishing an ASCII version, most network management systems can 
import a MIB module that is in ASCII format but not one in PDF 
format. Not publishing an ASCII version of the MIB module would 
negatively impact implementers and deployers of MIB modules and would 
make IETF review of MIB modules more difficult. 


The 802.1 WG web site requires a password for access to standards in 
development. The WG has started making the MIB module portion of 
their documents available as separate ASCII files during project 
development and allowing IETF participants to access these documents 
for pre-standard review purposes. 
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IEEE 802 has a policy whereby approved specifications are available 
for a fee for the first six months after approval, and freely 
available six months after they are approved. Once the specification 
is approved, the ASCII version of the MIB module is made freely 
available on the 802.1 WG website (see 
http://www.ieee802.org/1/files/public/MIBs/ or 
http://www.ieee802.org/1/pages/MIBS.html). 


There may be some issues about what gets included in the freely 
available specification. The SMIv2 MIB module alone will probably be 
insufficient; some discussion of the structure of the MIB, the 
relationship to other MIB modules, and security considerations will 
also need to be made available to ensure appropriate implementation 
and deployment of the MIB module within the Internet environment. 

For most implementers, the freely available specification six months 
after approval will be adequate. 


2.3. OID Registration for New MIB Modules 


The IETF and IEEE 802 have separate registration branches (arcs) in 
the Object Identifier (OID) tree. The Bridge MIB modules are 
registered under the IETF branch, and some assignments are maintained 
by IANA. The administration of the IEEE 802 arc is documented in 
[IEEE.802b]. 


As the IEEE 802.1 WG updates the IEEE 802.1 standards, the changes 
may include needed modifications to supplement the existing tables. 
This can be handled by developing an IEEE MIB module that augments 
the existing tables, or that reuses the indexing of the existing 
tables. The new modules can be registered under the 802.1 
registration branch, as was done with the 802.1X MIB module. 


When the changes only require the addition of one or two objects to 
the existing MIB modules, it may seem simpler for the 802.1 WG to 
define additional managed objects within the IANA-controlled 
registration tree. This approach is not recommended because of the 
difficulties of coordinating the changes between the two 
organizations, and of working the changes through the processes while 
trying to remain timely for each organization. Such additions would 
probably require approval by the Area Directors of Operations and 
Management after IETF MIB Doctor review. This would create 
dependencies between the work of the two organizations, and it might 
generate special cases for IANA to prevent the IEEE from being bogged 
down by IETF processes. 


The approach of developing an IEEE MIB module and defining a new 
compliance clause is simpler than dealing with such dependencies. 
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We need a balance between disruption to existing implementations and 
efficiency in making changes. Keeping the existing trees in their 
place minimizes disruption to existing implementations. 


3. Current Bridge MIB WG Documents 

3.1. Transferring Current Bridge MIB WG Documents 
During review of the legal issues associated with transferring Bridge 
MIB WG documents to the IEEE 802.1 WG, it was concluded that the IETF 


does not have sufficient legal authority to make the transfer without 
the consent of the document authors. 


RFC1286, RFC1493, and RFC1525 apparently precede any specific IETF 
document describing the copyright and intellectual property rights 
that authors grant to the IETF. RFC2674 falls under RFC 2026 
[RFC2026] rules. The three recent updates, [RFC4188], [RFC4318], and 
[RFC4363], fall under BCP 78, as documented in RFC3978 [RFC3978]. 


To permit them to perform maintenance and development of derivations 
works from documents containing the BRIDGE-MIB [RFC4188], P-BRIDGE- 

MIB, Q-BRIDGE-MIB [RFC4363], and RSTP-MIB [RFC4318], the IEEE 802.1 

WG will need to get permission from the authors and/or the companies 
to whom the authors have assigned their intellectual property rights 
in these documents. 


The IETF legal counsel for IPR matters and the IEEE Standards 
Association Manager of Standards Intellectual Property have agreed 
upon a sample letter for use by the IEEE 802.1 WG to request the 
necessary permissions from the authors, which is shown in Appendix B. 
The Bridge MIB WG chairs reviewed the author lists for the documents 
and provided the list of authors and their last known addresses and 
the documents with which they were associated to the IEEE Standards 
Association Manager of Standards Intellectual Property. 


The IETF will retain all the rights granted at the time of 
publication in the published RFCs. 


3.2. Updating IETF MIB Modules 


The updates to the Bridge MIB WG documents addressed changes 
documented in 802.1t, 802.1lu, 802.1v, and 802.1lw. These amendments 
were merged with 802.1D-1998 by the IEEE 802.1 WG to form 
802.1D-2004. The Bridge MIB WG did not address changes that resulted 
from that merger of documents. 
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The 802.1 WG will need to work through the management objects in the 
existing documents to determine whether they are consistent with new 
emerging specifications, including 802.1D-2004. During the final 
work on these documents in the Bridge MIB WG, there were some issues 
that we decided not to resolve, which allows them to be dealt with as 
part of the future work in the 802.1 WG. 


Work on the following items was deferred to the IEEE: 


o The ’autoEdgePort’ parameter (802.1D-2004 clause 17.3.3). 


o The BridgeID object. 
o References to 802.1D-1998 were not updated to 802.1D-2004. 
o Some objects in RFC4363 may have been obsoleted in 802.1D-2004 


o Description of dotlidPortOutboundAccessPriority seems wrong, but it 
followed the description in 802.1D-1998. 


o An issue was raised concerning dotldTpPortInFrames and 
dotlidTpPortOutFrames. This is an issue left over from RFC 1493. 


It was thought that the IEEE might be able to write separate 
documents containing updates to their technologies, such as 802.10, 
and to include a separate MIB module to augment the IETF MIB modules. 
However, recent changes to the IEEE standards are expected to require 
that the way the MIB tables are INDEXED be changed, which is not 
allowed under SMI rules, so the IEEE will need to rewrite the MIB 
modules and assign object identifiers under the ieee802 branch. 


For backwards compatibility, the existing IETF documents will still 
be valid and remain unchanged. 


If an 802.1 WG document must update or obsolete the IETF version of a 
Bridge MIB document, the 802.1 WG can create and submit an internet- 
draft to the IESG to be published as an RFC that points to the openly 
available IEEE copy and the IEEE standard. The IESG would need to 
approve the publication of the RFC. The RFC status would be 
reflected in the RFC-INDEX and also in the database, so it will be 
reflected on the RFC-Editor web page. Thus, we don’t have a problem 
with synchronization between the copies being published. 
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3.3. Clarifications on Variables Mapping and Compliance 


As the 802.1 WG handles the MIB development, the IEEE-standard 
"managed variables" and the associated IEEE MIB module objects will 
probably correspond, as many existing BRIDGE-MIB objects already 
correspond to 802.1 management variables, such as these from 802.10. 


Virtual Bridge MIB object IEEE 802.10-2003 Reference 
dotlqBase 

dotliqVlanVersionNumber 12.10.1.1 read bridge vlan config 
dotliqMaxVlanid 12.10.1.1 read bridge vlan config 
dotliqMaxSupportedVvlans 12.10.1.1 read bridge vlan config 
dotliqNumvlans 

dotlqGvrpStatus 12.9.2.1/2 read/set garp 


applicant controls 


IEEE allows definitions to be clarified in a manner that can actually 
alter the semantics of a managed variable somewhat, such as by 
changing the range. SMI rules generally prevent changing the 
semantics of defined MIB objects without obsoleting the current 
object and replacing it with an object with a new descriptor and OID 
registration. It is expected that, once both an IEEE MIB definition 
and the "managed variable" descriptions are in the same document, 
this problem will go away, as IEEE can update both at the same time 
in the approved manner. 


The need to fix a description in an IETF Bridge MIB module ina 
manner that would not be SMI legal would precipitate the need to 
define an IEEE MIB module, which might copy and replace the whole 
IETF MIB module or just add the necessary objects. Copying the IETF 
MIB module, changing the descriptors, and reassigning new IEEE OIDs 
would not be backwards compatible, and existing applications would 
need to be updated to access the new objects. Therefore it is 
recommended that the IETF MIB module not be copied and modified 
unless doing so is really necessary. 


The current practice in the 802.1 WG is to define the management 
variables and then a mapping table to associated MIB module objects 
(as shown above). The 802.1 WG could redefine the mapping from an 
IEEE managed variable to a new IEEE MIB object if the 802.1 
management variable semantics changed, thus allowing the 802.1 WG to 
‘do it right’ by SMI rules, supplementing the old MIB object with a 
new one. An updated mapping would be reflected in the compliance 
clause of the supplemental SMIv2 MIB module; it may be desirable to 
document the old mapping information in the description clause of the 
new object in the SMIv2 MIB module. 
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53 


Often, the mapping of 802 variables to MIB objects isn’t a 1:1 
mapping and doesn’t have to be. In the future, 802.1 variables may 
be invented with Web-based services in mind, but today the primary 
focus is on SNMP usage, and incorporating MIB modules into the specs 
themselves will likely further that focus. The level of redirection 
that exists today between 802 variables and MIB objects might be 
useful for the transition process when 802.1 management variable 
semantics are changed and MIB objects are supplemented. 


The existing Bridge documents represent the current state of bridging 
management, and the documents contain compliance clauses describing 
the current requirements to be compliant to the IETF standards. As 
the IEEE develops addition MIB modules, new compliance clauses will 
define the new "State of the art", without needing to obsolete the 
old MIB objects or the old compliance clauses. Therefore, the plan 
is that the current Bridge MIB modules will be "frozen in time", and 
updated only via the development of independent MIB modules by the 
802.1 WG. 


Mailing List Discussions 


The Bridge MIB WG has completed its documents, and the WG has been 
closed. 


The mailing list will remain open for a while. The mailing list 
administrators will discourage discussion of ongoing IEEE MIB module 
work on the Bridge MIB WG list and ask that the discussion be moved 
to the IEEE list, with a notice comparable to the following: 


This work is out of scope for the Bridge MIB WG mailing list. 

The appropriate mailing list for IEEE 802.1 MIB module discussion 
is STDS-802-1-L@listserv.ieee.org. 

To subscribe to the STDS-802-1-L list, go to 
http://www.ieee802.org/1/email-pages/ 

To see the general information about 802,1, including how they 
work and how to participate, go to http://www.ieee802.org/1/ 

To see presentations on the technology, go to 
http://www.ieee802.org/1/files/public/ and look in the docs2004, 
docs2005, and docs2006 directories. 


IETF MIB Doctor Reviews 


.1. Introduction 


The leaders of the Bridge MIB WG, 802.1 WG, IETF O&M area, and IEEE 
802 project have discussed having IETF MIB Doctors review IEEE 802 
developed MIB modules. This is a loose offering. 
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The expectation is that IETF will maintain a group of MIB Doctors who 
can review IEEE 802 - developed MIB modules, when a MIB Doctor is 
available and willing to do such review. It is the choice of 
individual MIB Doctors to provide technical advice and MIB Doctor 
reviews, and it is the willingness of the 802.1 editors and the 
support of the 802.1 chairs that determine whether the advice is 
accepted. This is not as formalized as it is in the IETF. 


In the IETF, the O&M area directors get "pushed" by other area 
directors to have MIB module documents reviewed by MIB Doctors when 
they start to come to WG Last Call, IETF Last Call, and certainly no 
later than when they appear on the IESG agenda. This demand requires 
prioritization of requests for MIB Doctor reviews by the area 
directors and prioritization by MIB Doctors when deciding whether to 
accept a request to review documents. 


When there are many IETF MIB documents in the queue and an IEEE MIB 
module document comes along for review, it will be the choice of the 
individual MIB Doctors whether to accept such a request, and how to 
prioritize their work. 


It will be helpful to MIB Doctors if the 802.1 chair requests a 
review early in development, after a MIB module design has been 
established but before an editor has done much detailing of the MIB 
module, so that a MIB Doctor can ensure that the table relationships 
and indexing are reasonable. Then it will be helpful if the 802.1 
chair requests reviews only for important ballots, such as sponsor 
ballots, rather than for every revision. 


It is recommended that the 802.1 WG establish its own MIB Doctor 
review team, to provide a review of MIB modules and to resolve most 
issues before requesting a review from the IETF MIB Doctors. This 
will help the 802.1 WG avoid delays caused by dependency on IETF MIB 
Doctors, and pre-reviewed documents will make it easier for an IETF 
MIB Doctor to find time to perform a requested review. The IETF is 
willing to make a loose offering to help the 802.1 WG establish and 
train such an IEEE MIB Doctor team. 


5.2. Review Guidelines 


The IETF has developed Guidelines for Authors and Reviewers of MIB 
Documents [RFC4181] so that authors and other WG members can check 
their document against the guidelines before requesting a MIB Doctor 
review. The 802.1 WG editor should use the RFC4181 guidelines before 
requesting a MIB Doctor review. 
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RFC4181 also intended to help editors by guiding MIB Doctors, so 
reviews by different MIB Doctors will remain fairly consistent. Each 
MIB Doctor has his or her own "pet peeves", and RFC4181 can help an 
editor know whether a review point is based on the consensus of the 
MIB Doctors, or on a pet peeve. 


Many SMI constraints, IETF editing constraints, and best current 


practices are discussed in RFC4181. However, many aspects of good 
MIB design (e.g., table fate-sharing, good index choices) are more 
art than science and are not discussed in the guidelines. Those 


might be more useful to other SDOs (and IETF editors) than guidelines 
relating to IETF boilerplate requirements. The MIB Doctors have 
discussed starting a design guidelines document. 


RFC4181 was used for reviewing the 802.1AB [IEEE802.1AB] and 802.1AE 
[IEEE802.1AE] documents. During those reviews, there were some 
anomalies about the IEEE use of the guidelines that we need to 
evaluate further. 


For example, in the IETF boilerplates, some of the terms have 
different meanings in IETF and IEEE, and different editing style 
guidelines are being used by the different bodies. It would be good 
to develop an 802 MIB boilerplate that is consistent with the IETF 
boilerplate, in purpose if not in terminology. 


The IETF uses [RFC4181] as a reference document for IETF documents 
containing MIB modules. It is recommended that in time IEEE 802.1 WG 
develop its own guidelines for IEEE MIB modules review. Until this 
happens, Section 3 (General Documentation Guidelines) and Section 4 
(SMIv2 Guidelines) in RFC4181 can be used, with the following 
exceptions and modifications: 


o In the introductory paragraphs of Section 3, the list of sections 
that must be included in a MIB document should be adapted to the 
IEEE needs and style guide. 


o Sections 3.1 through 3.4 apply as in the IETF document, with the 
mention that the IETF boilerplate could be edited to comply to the 
IEEE needs and style guide. 

o Section 3.5 (IANA Considerations) does not apply but may be 
replaced by a section with IEEE recommendations on naming and OID 


space assignments. 


o Sections 3.6 does not apply. 
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o Section 3.7 (Copyright Notices) does not apply and may be replaced 
with text corresponding to the IEEE copyright rules. The 
exception is the case where a document was originally issued by 
the IETF, and then taken over by the IEEE, in which case, unless 
the document authors agree otherwise, notices concerning the IETF 
copyrights (as described in Section 3.7) and IEEE copyrights must 
be included. 


o Section 3.8 (Intellectual Property) does not apply and may be 
replaced with a notice reflecting the intellectual property rules 
of the IEEE. 


o Sections 4.1 and 4.2 apply as in the IETF document. 


o Section 4.3 (Naming Hierarchy) applies with changes related to the 
OID root of the IEEE 802.1 MIB modules. 


o Sections 4.4 to 4.8 apply as in the IETF document 


o Section 4.9 applies, but some interesting problems may arise if 
IETF-designed modules are being taken over and continued by the 
IEEE. In order to comply to the requirement, the IEEE should 
continue to work and maintain the MIB module in the IETF OID 
space. 


An IETF MIB document template that contains all the required 
sections, following RFC Editor guidelines and the MIB review 
guidelines, is under development to help editors get started 
developing a MIB module document. The template will help MIB Doctors 
check new MIB modules more efficiently by providing the most up-to- 
date MIB module boilerplate, with sections in the preferred order, 
suggestions for what to include in certain sections, and the 
references required to support boilerplate text. It is recommended 
that the IEEE 802.1 WG establish a comparable template, following the 
IEEE editing guidelines and the RFC4181 guidelines, where 
appropriate. 


Such an IEEE template could simply be the management clause of an 
802.1 document, to be filled in with technology-specific information. 
In 802.1AB, the MIB clause was restructured to include modified IETF 
boilerplates and security considerations. This might be a good start 
on such an IEEE template. It would be helpful to MIB Doctors and 
editors if the unmodified template was available in ASCII format for 
automated comparison to a document in development, to verify that the 
appropriate boilerplate text is being used. 


When the 802.1 WG creates a PAR for 802.1 Bridge MIB maintenance, the 
creation of such a template might be included in the PAR. 
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The IETF MIB documents include the following text relative to the 
Internet Management Framework as part of the standard boilerplate: 


For a detailed overview of the documents that describe the current 
Internet-Standard Management Framework, please refer to Section 7 
of RFC 3410 [RFC3410]. 


Managed objects are accessed via a virtual information store, 
termed the Management Information Base, or MIB. MIB objects are 
generally accessed through the Simple Network Management Protocol 
(SNMP). Objects in the MIB are defined using the mechanisms 
defined in the Structure of Management Information (SMI). This 
memo specifies a MIB module that is compliant to the SMIv2, which 
is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 
[RFC2579], and STD 58, RFC 2580 [RFC2580]. 


It is recommended that the IEEE 802.1 standards that contain MIB 
modules include a similar sub-section in the MIB section of the IEEE 
document, and the appropriate references in their reference section. 


If IEEE 802.1 WG wants to craft its own guidelines, based on RFC4181, 
it will need to get the author’s permission. 


5.3. Review Format 
The 802.1 WG uses a template for comments, in the following format, 


so the onus to provide new text is on the reviewer, not on the 
editor. 


NAME : 

COMMENT TYPE: 
[E=Editorial, ER=Editorial Required] 
[T=Technical, TR=Technical Required] 

CLAUSE: 

PAGE: 

LINE: 

COMMENT START: 

COMMENT END: 

SUGGESTED CHANGES START: 

SUGGESTED CHANGES END: 


MIB Doctor reviews in the IETF are typically done in simple text 
email and often contain a long list of review comments. MIB Doctor 
reviews sometimes raise a general design issue rather than an issue 
with specific text, and some MIB Doctor comments refer to "global" 
problems, such as many objects that do not specify persistence 
requirements. 
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For global problems, IETF MIB Doctors are not required to provide the 
replacement text for each of these instances when doing 802.1 MIB 
module reviews. For example, if the naming of objects does not 
follow recommended conventions throughout the document, the MIB 
Doctor can point out the relevant clause in RFC4181 without 
suggesting each replacement object name. This is an important 
concession to the IETF MIB Doctors, to better suit the nature of 
their reviews, even though this puts the onus on the editor to fix 
the problem without explicit suggested changes. 


During the transition, the chair and vice-chair of the 802.1 WG are 
willing to accept simple emails, as long as they give enough 
information to understand what the problem is and how to fix it. The 
comments should include a problem description, a suggested 
resolution, and a page and line number. It would be helpful if 
comments are submitted in the preferred format, since this makes it 
easier for the editor to understand exactly what is being requested, 
to log the comment for review, and to review the comment in the 
meeting environment. The majority of MIB comments can usually be 
handled outside the official balloting process. 


5.4. Review Weight 


In the IETF, MIB Doctor review happens as part of the process of 
approving a standard. When a document is submitted to the IESG for 
approval as a standard, the area director/IESG requests a MIB Doctor 
review. Failure to pass the review can stop forward progress of a 
document in the standardization process at the discretion of the area 
director. MIB Doctors take their role seriously and perform detailed 
reviews. 


In the IEEE, the board that approves a standard is separate from the 
802.1 WG, and the reviews MIB Doctors will do according to this 
transition plan are done within the 802.1 WG. So a MIB Doctor review 
in the 802.1 WG is akin to an IETF WG chair asking for a MIB Doctor 
to sanity-check the work, rather than to a formal "MIB Doctor 
review". 


Formally, comments from any origin carry the same weight in 802.1; 
even voting status in the WG doesn’t make one’s comments more weighty 
than those of a non-voter. The 802.1 WG is not permitted to ignore 
any comments, regardless of origin. Serious comments are always 
taken seriously and never ignored. 


The IEEE typically requires that comments be officially submitted in 
a specific format, including proposed replacement text, which is then 
reviewed at the meetings, and the decisions are documented in 

disposition documents. These comments and dispositions are available 
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from the 802.1 private website. IETF participants can be given the 
password to the website by the 802.1 WG chair, so that they can see 
previous and current comments and dispositions. 


We should not give the impression that the IEEE documents have 
received the organized, coordinated, and formalized MIB Doctor review 
as done in the IETF, if such review is done on an ad hoc basis, and 
not necessarily as part of the advancement process. We need to be 
clear what is said, because the phrase "This document has passed MIB 
Doctor review" has quite some weight in the IETF. We need to clarify 
whether to describe the reviews done as having been done by an "IETF 
MIB Doctor" or "IEEE 802 MIB Doctor", or by a generic "MIB Doctor". 


MIB Doctor reviews be copied to the document editor, and to the 802.1 
chair. 


6. Communicating the Transition Plan 


The transition plan was discussed in the Bridge MIB WG at IETF61 and 
included a presentation, "Bridge MIB Transition to IEEE 802.ppt", 
available in the proceedings. 


The intent to transition was also posted on the Bridge MIB WG mailing 
list during notices of the Bridge MIB WG closure, including the WG 
Action announcement of February 15, 2006. 


The transition was discussed with the 802.1 WG at the San Antonio, 
San Francisco, and Garden Grove meetings. Presentations are 
available in http://www.ieee802.org/1/files/public/docs2004/ 
new-bridge-mib-transition-1104.ppt, http://www.ieee802.org/1/files/ 
public/docs2005/liaison-ietf-—congdon-0705.pdf, and 
http://www.ieee802.org/1/files/public/docs2005/ 
liaison-ietf-congdon-0905.pdf. 


7. Security Considerations 
This document describes a plan to transition MIB module 
responsibility from the IETF Bridge MIB WG to the IEEE 802.1 WG. It 
does not impact security. 


8. IANA Considerations 


Although this document discusses issues related to IANA assignment of 
OIDs, no IANA actions are required by this document. 
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Ds 


Intellectual Property Considerations 


On November 29, 2005, a teleconference was held that included Jorge 
Contreras, Scott Bradner, Bernard Aboba, Bert Wijnen, and David 
Harrington, to discuss the Intellectual Property Issues. The 
following is a summary of the conclusions: 


The IETF/ISOC gets a non-exclusive copyright license from RFC authors 
so that the IETF can publish RFCs, let third parties translate RFCs 
into other languages, let third parties reproduce RFCs as-is and 
create derivative works within the IETF standard process. The 
author(s) retain all of their rights other than the right to withdraw 
the permission for the IETF to do the above. 


If anyone (including the IEEE) wants to reproduce any RFC as-is, he 
or she can do so without any specific permission, but it has to be 
"as-is" (and that includes the ISOC copyright notice) since the right 
for third parties to reproduce RFCs is part of the rights the IETF 
gets from the author(s). 


The author(s) of a RFC can tell another group (e.g., the IEEE) that 
the other group can produce its own versions of the RFC, since the 
IETF does not get from the author(s) the right to stop them from 
doing so. 


If the author(s) give another group the permission to create 
derivative works, this has nothing (legally) to do with the IETF, 
since the agreement is just between the author(s) and the other 
group. Because of that, there is no reason for an ISOC copyright to 
appear, since the new document is not an IETF document. It would be 
nice if the other group were to include a note to say that their 
document is based on RFC XXXX, and the authors can insist on that if 
they want to, but the IETF has no formal role in granting 
permissions, so the IETF cannot require the pointer to the RFC. 


There is a desire to ensure that the IETF has sufficient rights to do 
derivatives of its own works. If the IETF decides, as part of a 
liaison arrangement with another SDO, to hand over maintenance of a 
specification to them, and if the authors give the other SDO 
permission to create derivative works, the IETF still retains the 
permission granted by the authors to create derivative works within 
the IETF standard process. 


Harrington Informational [Page 16] 


RFC 4663 802.1 MIB Transition September 2006 


The IETF strongly recommends that any derivative works developed by 
another standards body DO acknowledge that the work builds on prior 
IETF work, with reference to the RFC(s) the work derives from. MIB 
modules compliant to the IETF Best Current Practices documented in 
RFC4181 contain REVISION clauses that document how/where earlier 
versions were published. 


On January 11, 2006, another teleconference was held, to review the 
legal issues with Claudio M. Stanziola, the IEEE Standards 
Association Manager of Standards Intellectual Property. As a result 
of that discussion, the IETF Legal Counsel on IPR matters has crafted 
a sample document that other SDOs may use as a guideline for 
producing their own documents on "how to ask the question" to solicit 
authors’ permissions. The template is included in this document in 
Appendix B. 
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Appendix B. Sample Text for IEEE to Request Rights from Authors 
> "Dear Author, 


The IEEE P802.1 working group wishes to incorporate portions of IETF 
RFC XXXX (specifically YYY MIB modules) as part of IEEE Draft 
Standard P802.1 and to develop, modify and evolve such portions as 
part of the IEEE standardization process. 


Because the authors of contributions to the IETF standards retain 
most intellectual property rights with respect to such contributions 
under IETF policies in effect during the development of RFC XXXX, and 
because you are an author of said document, the IEEE hereby requests 
that you kindly agree to submit your contributions in RFC XXXX to the 
IEEE for inclusion in IEEE P802.1. Please note that IETF is aware of 
and supports this request. 


Attached hereto, please find a copyright permission letter template 
that we ask you kindly to sign and return, granting the 
aforementioned rights to the IEEE. 


Sincerely yours, IEEE" 
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Full Copyright Statement 
Copyright (C) The Internet Society (2006). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at 
letf-ipr@ietf.org. 
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